Events and actions in programming

Outbound requests and inbound webhooks are two directions of the bridge. This is the third: the Crestron Home programming surface. Every control you build publishes events a program can react to, and the driver exposes actions a program can call to drive a control — so a UI Dynamic tile is both a trigger for automation and something automation can operate.

The distinctive part — and the thing the previous driver was known for — is that the events and actions are dynamic: they are named after your controls, and they appear and disappear as you add and remove controls. There is no fixed pool of generic slots to map by hand.

Events — one set per control, named after it

Open this device's event list in Crestron Home programming. Instead of anonymous slots, you'll see entries named after your controls and their states. Each control publishes:

Event	Named	Fires when
Pressed	"Kitchen Fire — pressed"	The control is pressed — every press, even a status-only control that ignores presses.
Entered (one per state)	"Kitchen Fire — On"	The control enters that state, however it got there: a press, a program, a webhook, or an auto-revert.
Passthru (one per state)	"Kitchen Fire — On (passthru)"	Something asserts a state the control is already in. See below.

So a two-state button publishes five events — one pressed, plus an entered and a passthru for each of its two states — exactly the set the previous driver gave every button, now generalised to any number of states.

There is also one tile-level event:

• Tile pressed — fires when the room tile is set to act as a button and is tapped. It fires on every tap in that mode, even if the target control is missing or status-only, so a program can react to the tap itself. In the default Opens the buttons page mode a tap opens the page and does not raise this event.

Bind a scene, a notification, or any rule to the event you want — "Kitchen Fire — On" runs your "fire alarm" scene, "Gate — pressed" logs an entry.

The passthru event

An entered event fires only when the state actually changes to that state. A passthru event is the opposite: it fires only when a program (or webhook) asserts a state the control is already in, and it changes nothing.

It is a logic gate. A program can ask "is the Gate control currently Open?" by asserting Open and watching for the passthru — if it fires, the control was already open; if Gate — Open (the entered event) fires instead, it wasn't and has just changed. This lets a program test a condition without disturbing the control or re-running its outbound requests.

The Webhook received event

Separately from the per-control events, an inbound webhook can fire a Crestron Home event with no control involved (see Webhooks in). There is no per-name event — instead every fire-event webhook raises one event, "Webhook received", carrying the name the caller sent as its payload:

Payload	Value
name	The event name from the webhook (?event=doorbell → doorbell). Branch on this. It is caller-chosen and needs no setup in the driver.
value	An optional payload value; empty on the fire-event path.

Bind a rule to Webhook received, check the name, and run the scene you want — "when Webhook received and name is doorbell, run the Doorbell scene". One rule can handle every webhook name your integrations send.

Names, not slot numbers — and why bindings survive edits

Every event is tied to the control's stable internal identity, not its position on the tile or its name. That has a practical payoff:

• Rename a control, or relabel a state, and its events are relabelled in place — your existing bindings keep working and simply show the new name after the next save.
• Reorder the tile and nothing breaks — the events follow their controls.
• Only deleting a control removes its events (correctly — the thing they referred to is gone).

Rename freely

Because a binding follows the control rather than its label, you can rename a button to something clearer at any time without hunting down and re-pointing the scenes that use it.

Actions — drive a control from a scene or schedule

The driver exposes five programmable actions. Each addresses a control by its number (the 1…N you see in the setup app):

Action	Parameters	What it does
SetElementState	control number, state	Enter a state for real — fires that state's event and runs its On entering requests, exactly as a press would.
SetElementDisplay	control number, state	Move the control to a state without firing its event or running its requests — mirror an external truth back onto the tile without echoing it out.
ToggleElement	control number	Advance to the next state (cycles on a multi-step control).
PressElement	control number	Simulate a press — fires pressed and any On every press requests, then changes state as a real press would.
SetTileText	text	Set the room tile's status line.

The state parameter takes the state's label (e.g. On), the keywords on/off, or the state's index — whichever is easiest in your program.

SetElementState vs SetElementDisplay

Use SetElementState to make something happen — it enters the state and fires everything that hangs off it. Use SetElementDisplay to reflect a state the control is already in out in the world: it updates what the tile shows and the programming state without firing the event again or re-sending the outbound request. Reaching for the wrong one is the usual cause of a request firing twice, or a scene looping.

The surface keeps itself in step

You never register or map anything by hand. When you Save to processor in the setup app, the driver reconciles the programming surface with your controls in one pass: new controls' events and actions appear, deleted ones disappear, and renamed ones are relabelled. The change shows up in Crestron Home programming without a driver reload.

Actions address controls by number; deletes renumber

Events are tied to a control's stable identity, but the actions (SetElementState and friends) address a control by its number. Deleting a control renumbers the rest (the driver closes the gap), so an action that referred to control 3 may afterwards point at a different control. After deleting a control, check any programming actions that address one by number. See Migrating from the previous driver.

A worked example

To make "someone pressed the panic button" run a scene and light a keypad:

1. In the setup app, add a control named Panic, one momentary state, and save.
2. In Crestron Home programming, open this device's events, find "Panic — pressed", and bind your "Panic" scene to it.
3. To acknowledge from elsewhere — say a keypad button — add a PressElement action on control 1 (the Panic control's number) to that keypad's program, so pressing it drives the tile too.

The event and the action are two ends of the same control: one lets the tile trigger Crestron Home, the other lets Crestron Home drive the tile.